The description below uses the following definitions, which are provided here to improve the understanding:
Workflow (WF)—any sequence (or steps) of activities (steps of activities) required in order to accomplish an operation in the business world as well as in an application. Several actors, business and application components (see below) can be involved in the same workflow.
Business Component—a business entity, business logic, actor, activity, workflow and any of their sub-components.
Application Component—a screen, report, control, table, field, schema, and any other technical element of the information system (in the application environment as well as in the database environment).
Business Entity—an entity of the business world that is represented in the information system, such as a customer, an invoice, an employee, etc.
Business Logic—any business rule or calculation, such as commission, salary, etc.
Business Actor—a role that a user may play with respect to the system. Any actor-role has specific authorizations over each data item (see next).
Data Item—an attribute of a business component or a property of an application component. Any data item may be represented and stored as a field in the Generic Meta-Database rigid (GMD) schema of the present invention, as described in detail below.
Management System (M.S) of the database environment—the database engine/kernel that provides all operating utilities and services.
Management System (M.S) of the application environment—the engine/kernel of the development and execution of the IS application, which provides all operating utilities and services.
Editor in the context of an application environment—a framework wherein a developer can edit definitions and properties of a current application or business component (i.e. in a development mode).
Manager in the context of an application environment—an editor wherein an end user (with no programming background) can change definitions and properties of any application or business component in a run time mode of the application. All changes are codeless and refer to records changing (i.e., changing values of those records and/or adding new records and/or deleting records).
Business Data—values of data items related to business components.
Application Data—values of data items related to application components.
Run Time Application—executable state of an IS (after linking and compiling).
On the fly Total Application Editing—ability for codeless changing of any business component as well as any application component in a run time application.
FIG. 1 shows a typical architecture of a prior art information system 100. In the most general sense, IS 100 comprises an application environment 102 and a database environment 104. Communication and connectivity between the two environments is provided by a connection 106. Application environment 102 typically comprises one or more editors 110, for example a text editor for code editing in a text view, and a graphic editor for visual components editing in a graphical view, and a management system (M.S.) 112 used as application development and execution engine-kernel. M.S. 112 provides operating utilities and services, and is coupled to the editors and to external environments. Applications environment 102 further comprises application data 114 related to application component definitions and properties, which are used to define the specific appearance and behavior of each component. Database environment 104 (usually based on a commercial relational database management system (RDBMS)) typically comprises a specific business schema 116, which represents business entities that are specific for each application according to its functionality; a management system 118 used as a database development and execution engine-kernel, providing operating utilities and services, and is coupled to the schema and to external environments; and business data 120, stored in the schema. An example of a specific business schema 116 may be seen in FIG. 7.
Traditional application and database environments are described in detail in various sources in the literature. For example, the application environment (editors and components properties) is described in “Visual Basic 6” by H. M Deitel, P. J. Deitel and T. R. Neito, Prentice Hall, 1999. Specifically, chapter 2, pages 25-49 therein describe an integrated development environment, FIG. 3.6, p 55 describes a code window (“text editor”), and chapter 16.16, pages 694-695 describes an object browser. A system architecture is described in chapter 10, pages 215-238 of “Software Engineering” by I. Sommerville, Addison-Wesley, 6th edition, 2001. The database environment (schema, management system and data) is described in “Fundamentals of Database Systems” by R. Elmasri and S. B. Navathe, Addison-Wesley, 3rd Edition, 2000. Specifically, chapter 2, pages 23-39 therein describes database system concepts and architectures, chapter 7.1, pages 196-202 therein describes relational model concepts, and chapter 7.2, pages 202-208 describes relational constraints and relational database schemas. Further references may be found in “Database Systems” by T. Connolly and C. Begg, Addison-Wesley, 3rd Edition, 2002. Specifically, chapter 2, pages 33-66 describes the database environment, and chapter 15, pages 440-475 describes the logical database design for the relational model.
In existing IS applications, specific business database schema 116 is designed according to the specific business objects and entities that are relevant to the required functional use of the specific system. It therefore relates to specific tables and specific business data items. Application components such as those related to user interfaces are specific as well, and handled as part of the application environment. Each specific component such as a field or a control on a screen has its definitions and properties, which are represented as data 114 in the application environment.
The development tools existing in prior art IS architectures are characterized by two main disadvantageous features: (a) the business schema is not stable to functional changes, because every business entity/object has to be represented in a separate table or tables. Moreover, each attribute of a business entity/object has to be represented in a separate field; (b) the application components and business components are defined and applied by code and not by application of general mechanisms on relevant data stored in a database. As a result, application development and maintenance processes in existing IS architectures are slow, complicated, and require extensive skilled human resources (programmers, database administrators, quality assurance manpower, etc.). For example, adding a new business entity, or adding or changing an attribute of a business entity (e.g. adding tables or fields) has significant consequences in terms of the need to update the application (screens, reports, logic, etc.), because the business schema is changed.
Therefore, it would be advantageous to provide an IS architecture based on a generic-rigid schema that represents not only business entities but also entire application and business components in a generic and rigid way. That is, it would be advantageous to have a generic-rigid schema that can embody and support any business functionality and any applicative functionality, without a need for any change or any adjustment in the database schema structure. A “generic way” as used herein can embody and support any business and applicative functionality; a “rigid way” as used herein can embody and support these functionalities in a fixed schema that needs no change or adjustment, no matter what the business or applicative changes are.